linux: use screenshot portal for Wayland QR scanning - #4622
Conversation
8a3f6b2 to
f2eee93
Compare
There was a problem hiding this comment.
This subscribes to Response only after the Screenshot call has returned. The portal can emit Response right behind the method reply (on failure paths), and although the signal is unicast (directed at the caller, so the bus delivers it without a match rule) QtDBus matches incoming signals against registered hooks at dispatch time and silently drops unmatched ones. Any Response dispatched before connect() registers the handler is discarded. So if the request fails fast (or the main thread is preempted between waitForFinished() and connect()), the response can be lost, and this then waits the full 60s with every window hidden.
The Request docs recommend passing a handle_token in the options, precomputing the request path (/org/freedesktop/portal/desktop/request/<sender>/<token>, where <sender> is the caller's unique name with the leading : stripped and . replaced by _), subscribing before the call, and verifying the returned handle matches (updating the subscription if it doesn't, for portals older than 0.9).
|
@thomasbuilds Good catch, I’ve updated this to use handle_token, subscribe to the expected request path before calling Screenshot, and keep the returned-handle fallback for older portals. |
|
|
|
It looks like this PR removes |
4 participants
Fixes #4607
What changed
This updates
OSHelper::grabQrCodesFromScreen()so the Transfer page's "Grab QR code from screen" action can work on Wayland.On Wayland,
QScreen::grabWindow(0)does not capture the desktop, so theexisting QR screen scan path silently failed. This PR detects Wayland on Linux
and uses
org.freedesktop.portal.Screenshotinstead. The existingQScreen::grabWindow(0)path is still used for non-Wayland platforms.The portal path:
prompt
portal is unavailable
Why
Wayland intentionally blocks direct screen capture APIs like
QScreen::grabWindow(0). The XDG screenshot portal is the desktop-supportedway for applications to request a screenshot under Wayland while keeping user
consent in the flow.
This keeps the existing Transfer page behavior where possible, instead of
leaving the button doing nothing on Wayland.
Notes
This adds
Qt5DBuson Linux desktop builds so the application can communicate with the XDG desktop portal.